.. :validated: 3.1.0


Особенности работы системы при гранулярном управлении доступом
--------------------------------------------------------------

Особенности работы привилегий
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. list-table:: Особенности работы привилегий
   :widths: auto
   :header-rows: 1
   :class: longtable

   * - Привилегии
     - Особенности работы привилегий
   * - - Print Servers - Read
       - Event Log Servers - Read
       - Event Registration Rules - Add
       - Monitoring Servers - Read
       - Installation Servers - Read
       - Repository Servers - Read
       - DHCP - Read
       - File Servers - Read
       - Domain Controllers - Read
       - Group Policies - Read
       - Software Policies - Read
       - Automation Task Attributes - Manage
       - Automation Tasks - Manage
       
     - Привилегии позволяют видеть в базе данных автора изменений для ГП, политик ПО, заданий автоматизации, правил сбора событий и серверных подсистем (DHCP, серверы печати и т.д.)
       
   * - - Computers - Read
       
     - Привилегия позволяет видеть в базе данных информацию об установленных на компьютер подсистемах
       
   * - - Users - Return from trash
       
     - Для успешной активации роль с данной привилегией должна быть назначена на корень домена (при этом признак «Включая дочерние подразделения» может быть как установлен, так и не установлен)
       
   * - - Users and Groups Settings - Manage
       
     - Роль с данной привилегией должна быть привязана к корню домена с установленным признаком «Включая дочерние подразделения»
       
   * - - Users - Read
       
     - Привилегия дает права на чтение дополнительных атрибутов пользователей только через API и в базе данных.
       
       Для чтения дополнительных атрибутов пользователей через интерфейс ALD Pro (вкладка «Дополнительные сведения» карточки пользователя) необходимы две привилегии:
       
         * Users - Read
         * Users and Groups Settings - Read
       
   * - - Computers - Remote access
       
     - До версии 2.4.0 привилегия распространялась на весь домен. С 2.4.0 привилегия имеет привязку к подразделению
       
   * - - SUDO Rules - Modify
       
     - Для возможности назначения правила SUDO на всех пользователей домена при выборе пункта «Любой пользователь» на вкладке «Пользователи» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения».
       
       Для возможности назначения правила SUDO на все компьютеры домена при выборе пункта «Любой компьютер» на вкладке «Компьютеры» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения»
       
   * - - HBAC Rules - Modify
       
     - Для возможности назначения правила HBAC на всех пользователей домена при выборе пункта «Любой пользователь» на вкладке «Пользователи» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения».
       
       Для возможности назначения правила HBAC на все компьютеры домена при выборе пункта «Любой компьютер» на вкладке «Компьютеры» необходимо, чтобы привилегия входила в роль, которая привязана к корню домена с активным признаком «Включая дочерние подразделения».

Особенности работы методов PUT и PATCH
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

При работе этих методов могут не возвращаться ошибки об отсутствии прав на операции изменения сущностей.

При методах PUT и PATCH привилегия работает следующим образом:

1. выполняется метод GET, который возвращает сущность в текущем состоянии;
2. выполняется метод PUT или PATCH, который меняет сущность;
3. выполняется метод GET, который возвращает измененную сущность.

Если отправлять PUT или PATCH запрос с телом запроса без изменения сущности, выполняется 1-й шаг - метод GET, который возвращает сущность в текущем состоянии, а метод PUT (2-й шаг) не выполняется, так как запись не меняется.

В этом случае пользователю без прав на изменение сущности (методами PUT или PATCH) системой не будет выдана ошибка об отсутствии прав на операцию, т.к. эта операция не выполнялась.

Если отправить PUT или PATCH запрос с изменением от пользователя, не имеющим на это права, валидация прав отработает корректно.

Возможные ответы системы на запросы GET при отсутствии прав на выполнение операции
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

При отсутствии прав на запросы GET система может выдавать следующие варианты ответов:

- сообщение об ошибке на выполнение операции из-за отсутствия прав:

.. code-block:: 

    // {
        "error": "Отсутствуют права на выполнение данной операции",
        "success": false,
        "code": "ForbiddenError"
    }

.. code-block:: 

    // {
        "error": "Отсутствуют права на выполнение данной операции",
        "success": false,
        "code": "DeniedIPAError"
    }

- успех операции с пустыми списками, для которых указано ненулевое количество записей:

.. code-block:: 

    // {    "data": [],    "total": 45,    "success": true}

- успех операции с пустыми списками, для которых возвращается ноль записей:

.. code-block:: 

    // {    "data": [],    "total": 0,    "success": true}